Most people advice against rewriting every (internal) url to include the sessionId (both GET and POST).

The standard argument against it seems to be:
  If an attacker gets hold of the sessionId, they can hijack the session.
  With the sessionId in the url, it easily leaks to the attacker (by referer etc.)

But what if you put the sessionId in both an (encrypted) cookie and the url. if the sessionId in either the cookie or the url is missing or if they do not match, decline the request.

Let's pretend the website in question is free of xss holes, the cookie encryption is strong enough, etc. etc.

Then what is the increased risk of rewriting every url to include the sessionId?

UPDATE:
@Casper That is a very good point.

so up to now there are 2 reasons:

• bad for search engines / SEO if used in public part of the website
• can cause trouble when users post an url with a session Id on a forum, send it trough email or bookmark the page

apart from the:
  It increases the security risk, but it is not clear what the increased risk is.

some background info:
I've a website that offers blog-like service to travellers. I cannot be sure cookies work nor can I require cookies to work.

Most computers in internet cafes are old and not (even close to) up-to-date. The user has no control over them and the connection can be very unreliable for some more 'off the beaten path' locations.

Binding the session to an IP-address is not possible, some places use load-balancing proxies with multiple IP addresses. (and from China there is The Great Firewall).

Upon receiving the first cookie back, I flag cookies as mandatory. However, if the cookie was flagged as mandatory but not there, I ask for their password once more, knowing their session from the url.

(Also cookies have a 1 time token in them, but that's not the point of this question).

UPDATE 2:

The conclusion seems to be that there are no extra *security* issues when you
expose you session id trough the URL while also keeping a copy of the
session id in an encrypted cookie.

Do not hesitate to add additional information about any possible security implications